Hackers Underworld 2: Forbidden Knowledge/Hackers Underworld 2: Forbidden Knowledge.iso/VIRUS/VIRUS101.002

Internet Message Format | 1994-07-17 | 18KB

From: [e-mail] (George Woodside)
Newsgroups: comp.sys.atari.st,comp.sys.apple,comp.sys.mac,comp.sys.ibm.pc
Subject: Virus 101 - Chapter 2
Date: 6 Mar 89 14:00:21 GMT

In response to a lot of the mail I've received:
1) You haven't missed the "rest of the chapters". I'm posting them as I
   get them written.

2) You may not agree with me. I tried to set down the definitions and
   terms as I would be using them, for the benefit of those who weren't
   familiar with them. This whole area is rather vague, and most of us
   in the trenches and making up the rules, as we learn the game.

When we left our virus at the end of Chapter 1, it had managed to get
itself installed in our system by being present on the boot sector of a
disk in the machine at cold start or reset.

Another way a virus may be installed is via a trojan horse program. Trojan
horses come in many flavors. Some disguise themselves as programs which
provide some useful function or service, while secretly doing something
else. The something else may be installing a virus, sabotaging some part of
a disk, setting up hooks to steal passwords on time sharing systems, or
whatever else you can imagine. In the event of the virus installer, the
trojan horse has a bit more flexibility than a typical boot sector virus,
simply because it doesn't have to fit itself into a relatively small space.
Since it is hiding in a larger program, it can be whatever size is
necessary to accomplish the task.

A typical boot sector contains information about the layout of the disk it
resides upon. This block of data requires 26 bytes. The first three bytes
of the boot sector are left available for an assembly language "jump"
command, to allow the execution of the code to skip over the boot sector's
data block. And, the boot sector must add up to the proper magic number to
have executable status. That will require another two bytes, since the
checksum is a 16 bit value. So, 31 bytes are allocated. Since (at least in
the 68000 family) machine instructions are always 16 bits and must begin on
an even address, 32 of the 512 bytes in the boot sector are not available
to any executable program. So, there are 480 bytes available for the
executable code. Machine instructions vary in length, depending upon what
they do, and how much additional information is required. In the 68000,
instruction lengths vary from one to five words, but a reasonable average
instruction length for a program is just over two words. That translates
the 480 bytes to 120 instructions.

The virus must contain the code to install itself, reserve the memory it
occupies to keep subsequent programs from over-writing it, spread itself to
other disks, and whatever it really intends to do once it decides it is
time to act. That's quite a bit of code to fit into 120 instructions,
unless it extends itself by loading some other part of the disk, or a file.

Files are pretty much out of the question. Most computer users would notice
if some file they didn't recognize started popping up on a lot of their
disks. There are attributes settable in a disk directory which can be used
to tell the operating system that certain files are "Hidden" or "System"
files. If the file had the proper status bits set, it could prevent itself
from appearing in normal disk directory displays. There are, however, more
flexible disk directory listing programs which will display the entries for
these files, as well as normal files. There is also the problem of the
space the hidden file occupies, as well as the directory entry. The space
available on the disk will be less than it should be, since the hidden file
is present. These symptoms would not escape detection for long.

A more effective method is the use of specific disk sectors. The standard
disk layout covered in the preceeding chapter mentioned such things as File
Allocation Tables, and disk directory space. In a standard format Atari
disk, for example, each FAT is 5 sectors long, and the directory is 7
sectors long. That is more than enough FAT space to accomodate the entire
disk. A virus in need of more space than 480 bytes might write the
remainder of itself in the last sector of the FAT (I have one that does
this). It might also write itself in the last sector of the directory,
taking advantage of a quirk in the operating system.

When a disk is formatted, all data sectors are normally filled with a
pre-defined value, E5 (hexadecimal). The directory and FAT space is usually
set to 00. When a directory entry is made active, the file name is written
in the directory, along with some other required information. When a file
is deleted, the first byte of the directory entry is set to E5. That makes
the entry available again. This is a carry over from the early days of
floppy disks, when where the directory would exist on a disk was not as
well defined. The directory entries had to appear as empty on a freshly
formatted disk, so E5 was used as a deleted entry mark. That way, no matter
where the directory was, a freshly formatted disk would always appear as
empty. Now, since disk formats are more flexible, the directory is located
by parameters, and normally the entire directory space is zeroed at
formatting time. Since an active entry will have some legitimate ASCII
character in the beginning of the file name, and a deleted entry will have
E5 in the first byte, it is generally assumed that encountering a directory
entry with a value of 00 in the first byte indicates that the entry has
never been used. Since directory entries are used (and deleted ones
re-used) on a first-found basis, finding one with 00 means that not only
has it not been used, but none of the ones following it will have been used
either. Consequently, most software stops looking at the directory entries
when a 00 entry pops up. If there are several more sectors available, there
may be something hiding out there, beyond the last used entry. While this
method of hiding is not foolproof, the typical virus is not concerned about
being bulletproof in all cases. It just has to survive long enough to
reproduce itself, and it has half the battle won. As long as it keeps
spreading, sooner or later it will survive long enough to do the task it is
designed to do, then it wins both halves of the battle.

There are other ways for the virus to get additional disk space. Typically,
floppy disks are not used up a sector at a time, but rather in groups of
sectors. Each group of sectors is referred to as a data "cluster". The
number of sectors in a cluster is variable, and is one of the parameters
stored in the boot sector. If the number of data sectors on the entire
disk, minus the boot sector, FATs, and directory, is not an exact multiple
of the number of sectors in a data cluster, the remaining sectors will
never be used by the opearting system. A clever virus can find them and
hide there. The inconvenience of this is that the unused sectors would
normally be at the end of the last track of the disk, causing long (and
noticeable) disk seeks to load or spread the virus.

There is a parameter in the boot sector designed to permit the disk to have
sectors reserved for any purpose, and not accessed as part of the normal
data area. A virus could also use this method to extend itself, but it,
too, has shortcomings. Using this feature requires the parameter to be set
when the disk has absolutely no data on it. Reserving sectors causes the
start of the data area to be moved further into the disk. While the data
area would be moved, the data already on the disk would not. Consequently,
altering the reserved sectors parameter would make all files on the disk
garbage. (They could be returned to proper status by restoring the original
value to the reserved sectors parameter, providing no disk write had
occurred.) There would also be the problem of the disk's free space being
less that it should.

Consequently, if a virus needs extra space, using prescribed system
features or hidden files is not a good choice, since it is too easily
detected. The approach used so far is to hide in sectors unlikely to be
used, and hope to spread before they get clobbered